Modern database systems store ever-increasing amounts of data. This data is typically stored as records of database tables within a database-optimized data store. This storage facilitates access, reporting, modification, and backup of the data using known database techniques.
Due to performance and/or storage capacity concerns, it may be desired to occasionally delete data from a database system. This deleted data is preferably archived so as to be accessible at a later date if needed. Archived data is stored in archive files, which are typically non-indexed information structures. These structures are not formatted in a manner which allows a database system to directly access the data stored therein. Rather, the data stored in an archive file must be reloaded into a database system (e.g., in the form of database tables) in order for the database system to use the data.
Conventional techniques for reloading archived data are problematic. For example, each archive file is generated based on an associated “archiving object”. An archiving object describes table structures, the context of the data to be archived, and various archiving preferences. A developer creates a “load back” report to control the reloading of an archive file's data based on the archive file's associated archiving object. However, because archiving objects may be freely customized and configured, a new load back report must be manually created for each different archiving object whose associated archive files are to be reloaded. This effort consumes significant resources and is prone to errors.